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Improving  Software  Architecture  Competence 

Most  of  the  work  in  architecture  to  date  has  been  technical 

•  Design  and  creation 

•  Evaluation  and  analysis  of  architectures 

•  Styles  and  patterns 

•  Architectural  reuse  and  software  product  lines 

•  Architectures  for  particular  domains 

•  Architectural  re-engineering  and  recovery 

But  architectures  are  created  by  architects... 

•  How  can  we  help  them  do  their  best  work? 

•  What  does  it  mean  for  an  architect  to  be  competent? 

•  How  can  an  architect  improve  his/her  competence? 

...working  in  organizations. 

•  How  can  we  help  an  organization  help  their  architects  do  their  best  work? 

•  What  does  it  mean  for  an  organization  that  produces  architectures  to  be  competent? 

•  How  can  an  organization  improve  its  competence  in  architecture? 
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Opening  discussion  questions  - 1 


i.  Can  you  given  an  exemplary  example  of  competence,  or  a  pathological 
example  of  competence?  How  would  you  have  measured  or  predicted 
these? 

•  Architect  needs  to  understand  roles,  understand  the  scope  of  work.  Ultimately,  they 
need  to  understand  the  organization. 

•  Be  a  good  communicator.  Frequency  of  communication  is  a  measure. 

•  Experience  and  knowledge  in  the  domain,  having  built  similar  systems. 

•  Embracing  the  most  recent  innovations  in  the  field  is  not  necessarily  a  good  thing. 

•  The  architect  should  be  aware  of  the  skill  set  available  in  the  team. 

•  Specialized  skills  (e.g.,  security,  performance). 

•  What  processes  has  the  architect  used?  What  was  his  role  then? 

•  Is  the  architect  able  to  answer  the  hard  questions  about  the  design?  Did  the  code 
ended  up  like  the  original  architecture? 

•  If  the  architecture  withstood  the  test  of  time,  it’s  a  sign  that  the  architect  did  a  good 
job.  If  the  architecture  did  not  withstand  the  test  of  time,  we  can’t  hold  it  against  the 
architect  because  other  factors  may  have  affected  the  end  result. 

•  There’s  the  competence  on  the  acquirers  side  and  the  providers  side. 
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Opening  discussion  questions  -  2 


2.  What  do  you  think  is  the  value  of  architecture  to  an 

organization?  For  each,  how  might  you  measure  the  value? 

•  Decrease  the  amount  of  verification  and  validation  of  the  product.  The  organization 
wants  to  move  the  cost  of  V&V  on  the  product  to  the  V&V  of  the  architecture. 

•  Is  there  recognition  of  the  architect  in  the  organization?  Definition  of  the  role 
‘architect’? 

•  Are  there  groups  within  the  organization  where  architects  can  share  experiences? 

•  Having  dedicated  architects  is  a  function  of  the  size  of  the  company. 

•  Does  the  software  process  in  use  prescribe  architecture-related  activities  (e.g., 
producing  a  SAD)?  Are  there  standard  architecture  artifacts  as  outputs? 

•  Are  there  experts  in  different  quality  attributes  available  to  help  in  the  software 
architecture  of  the  systems. 

•  How  does  the  organization  staff  development  teams? 

•  Pathological:  some  organizations  don’t  do  better  in  architecture  saying  they  don’t 
have  time/money  for  that  and  already  know  what  to  do. 

•  Can  the  managers  speak  the  language  of  architecture? 
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Other  questions 


How  can  we  convince  an  organization  that  architecture  is  important? 

•  It’s  difficult.  You  have  to  engage  technical  people  that  have  a  say  within  top 
management.  These  champions  of  architecture  work  need  to  be  able  to 
describe  the  benefits  and  artifacts  that  architecture-centric  work  would 
generate. 

•  Sacrifice  training  budget  to  send  management  to  SEI  or  Zachman  courses 

•  Training  can  be  informal  like  brown  bag  lunches. 

•  You  can  incentivize  people  to  create  good  architectures. 

•  You  can  incentivize  developers  not  to  ignore  the  architecture. 

•  You  can  create  career  path  for  architects. 

•  You  can  certificate  architects. 

•  Organizations  that  do  these  things  are  more  architecturally  competent. 

•  To  stimulate  people  to  participate  in  QAW,  we  tell  them  it’s  their  interest  to  be 
there. 
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Other  questions 


How  can  we  convince  a  manager  that  architecture  is  important? 

•  Discuss  the  impact  of  not  finding  problems  early  in  the  design  phase. 

•  If  the  customers  ask  for  it,  manager  will  do  it. 

•  If  we  can  tell  managers  how  much  money  will  be  saved  with  architecture,  they 
will  buy  it. 

How  can  we  measure  the  ROI  of  architecture? 

•  Tell  executive  that  the  way  business  is  done  can  change  dramatically  in  a 
short  period  of  time  and  architecture  is  a  mechanism  for  gaining  control  of 
these  changes. 
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Possible  value  of  architecture 


Predictability  in  cost  and  schedule  and  quality 

•  Measure:  Variance  between  predictions  and  actual 

•  Hypothesis:  Architecture  practices  lead  to  lower  variances 

Ability  to  achieve  system  that  meets  its  requirements  (which  presumably 
reflect  business  goals) 

•  Measure:  Does  it  or  doesn't  it?  What  percentage  of  requirements  are  met? 
What  percentage  of  high-priority  requirements  are  met? 

•  Hypothesis:  Architecture  practices  lead  to  higher  achievement 
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Architectural  duties:  How  can  we  measure  value? 


Architecting 

•  Overall 

•  Creating  the  architecture 

•  Architecture  evaluation  and  analysis 

•  Documentation 

•  Existing  system  and  transformation 

Life  cycle  phases  other  than  architecture 

•  Requirements 

•  Testing 

•  Coding  and  development 

Technology  related 

•  Future  technologies 

•  Tools  and  technology  selection 

Interacting  with  stakeholders 

•  Overall 

•  Clients 

•  Developers 

Management 

•  Project  management 

•  People  management 

•  Support  for  project  management 

Organization  and  business  related 

•  Organization 

•  Business 

Leadership  and  team  building 

•  Technical  Leadership 

•  Team  Building 
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